Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add separate checkout info block to buildscripts. #3483

Closed
wants to merge 20 commits into from

Conversation

mitchell-as
Copy link
Contributor

@mitchell-as mitchell-as commented Sep 9, 2024

StoryDX-3024 Non-versioned buildscript information is clearly denoted

  • Use triple-backticks to separate checkout info from buildscript. Using triple-quotes will require a new parser and/or lexer. Since we're experimenting, let's use what we have.
  • Buildscripts always have an AtTime (it's no longer optional). I believe we had it optional for compatiblity with build expressions that didn't have a separate commit time, but all build expressions now have an associated commit time from what I can tell.
  • Renamed localcommit package to checkoutinfo
    • checkoutinfo is a primer property and all runners go through it to get commit IDs and work with build script (initialize, update, etc.).
    • Removed runbits/buildscript/file.go in favor of this package.
  • Changed buildplanner.GetBuildScript() to additionally accept an owner, project, branch, and commitID. It uses these fields to construct the "Project" field in the commit info section of buildscripts.
  • state reset LOCAL will always re-initialize a build script.
  • Internal change in the raw buildscript format to not store strings with quotes. (Unmarshaling strips quotes, and marshaling adds them back.)
  • Users are shown a warning if they attempt to use an outdate build script (state install, etc.).

Comment on lines +968 to +974
pjf := NewProjectField()
pjf.LoadProject("https://" + host)
pjf.SetNamespace(params.Owner, params.Project)
if params.BranchName != "" {
q.Set("branch", params.BranchName)
pjf.SetBranch(params.BranchName)
}

u.RawQuery = q.Encode()
params.ProjectURL = u.String()
params.ProjectURL = pjf.String()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to avoid code duplication. I was using NewProjectField() in the buildplanner to construct the "Project" field in the checkout info block of buildscripts, and found that we can do the same thing here.

@mitchell-as
Copy link
Contributor Author

Test failure is unrelated to this PR.

@mitchell-as mitchell-as marked this pull request as ready for review September 10, 2024 16:03
@mitchell-as mitchell-as reopened this Sep 10, 2024
Copy link
Member

@Naatan Naatan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see comment on the Initialize function. I didn't finish the review as I imagine this comment may bring about some significant changes.

internal/runbits/buildscript/file.go Outdated Show resolved Hide resolved
internal/runners/reset/reset.go Outdated Show resolved Hide resolved
internal/runners/reset/reset.go Outdated Show resolved Hide resolved
pkg/buildscript/unmarshal.go Outdated Show resolved Hide resolved
pkg/buildscript/unmarshal_buildexpression.go Show resolved Hide resolved
pkg/buildscript/unmarshal_buildexpression.go Show resolved Hide resolved
pkg/checkoutinfo/checkoutinfo.go Show resolved Hide resolved
Call out to build scripts to get and set commit IDs instead of using another package.

The build script packages will determine if build scripts are enabled and use a mediator if necessary.
@mitchell-as
Copy link
Contributor Author

mitchell-as commented Sep 12, 2024

I expect more churn. I'm flagging for early review as I doubt it'll pass all tests in its present state, but the idea is in place.

Copy link
Member

@Naatan Naatan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things stand out to me at a high level:

  • I think checkoutinfo should probably be a primer property
    • Because the reliance on cfg already implies primer anyway, and similar to project/projectfile this will almost always be relevant for every command.
  • We're still sourcing project URL info from the project package
    • eg. owner, name and branch are still being sourced from project. I'd expect to see these sourced from checkoutinfo, and have legacy methods on the project methods like we did with the commitID. These legacy methods should probably only be called from checkoutinfo, but there might be edge cases.

"github.com/ActiveState/cli/pkg/checkoutinfo"
)

func CommitID(path string, cfg configurer) (strfmt.UUID, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move this to checkoutinfo? I get where you're coming from, but runbits are about sharing controller logic. This isn't controller logic. And this type of muliplexing is exactly what the checkoutinfo package is intended for.

@mitchell-as mitchell-as force-pushed the mitchell/dx-3024 branch 3 times, most recently from b3810dc to a8c8a35 Compare September 16, 2024 16:22
@mitchell-as
Copy link
Contributor Author

I made checkout info a primer property and I think I addressed your other line item (sorry if I overlooked it; lots of changes).

I've updated the PR description with an overview of the entire thing.

} else if !errors.Is(err, ErrBuildscriptNotExist) {
return "", errs.Wrap(err, "Could not get build script")
}
// Fall back on activestate.yaml.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the buildscript exists then I think we should just fail here. Falling back to the as.yaml at that point is working around some bug.

Comment on lines +54 to +62
return c.project.Owner()
}

func (c *CheckoutInfo) Name() string {
return c.project.Name()
}

func (c *CheckoutInfo) Branch() string {
return c.project.BranchName()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should behave the same as the CommitID() function; ie. collect from buildscript if opted in.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also their Set() methods should be in checkoutinfo also.. otherwise we're not syncing the buildscript when those are changed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to remove the Owner(), Name(), and Branch() accessors since they're not used externally. The ACs make no mention of having checkoutinfo being the gatekeeper of accessors, just for setters like you mentioned here.

If we make checkoutinfo the sole source of truth for Owner, Name, and Branch, then this PR will double in size. I'd rather do that in another ticket.

Comment on lines +131 to +133
if !fileutils.FileExists(buildscriptPath) {
return c.InitializeBuildScript(commitID)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please error out with the "run state reset LOCAL" error. This file should exist if opted in, it not existing is an error condition. Working around this magically like this is what we did originally and it caused a lot of issues.

return strfmt.UUID(commitID), nil
}

func (c *CheckoutInfo) BuildScript() (*buildscript.BuildScript, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about having this, UpdateBuildScript(), and InitBuildScript() inside checkoutinfo. Checkoutinfo is from a consumer point of view about project information, not about buildscripts, that's just an under the hood mechanic.

Also, we don't handle project retrieval or initialization in this package, so handling buildscripts here feels inconsistent.

Let's put it this way: if we KNOW we want a buildscript, or a project/projectile (the pkg) then we should not be using checkoutinfo.

@mitchell-as
Copy link
Contributor Author

This is a mess. I'm going to restart.

@mitchell-as
Copy link
Contributor Author

Restarting is more of a mess, so this'll have to do.

@mitchell-as mitchell-as reopened this Sep 26, 2024
@mitchell-as
Copy link
Contributor Author

No, I can't do it in this PR. I'll start from scratch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants